Could you add a change to a model in a second commit on this PR (that we will shortly revert/undo) to test that this fails as expected please?

Sure! I would do it later after this CI finished (make sure it could pass now)

alembic check does not check if there's a difference between ORM models and migration files as you described. It only checks if there are pending upgrade operations in the migration file. For example, if you upgraded to Airflow 3.0 and your database migration head is still at Airflow 2.7.0. Running alembic check will detect that you have not upgraded your database to Airflow 3.0. As Ash suggested, you can add a field to a model and let us see that the CI fails due to the alembic check detecting the added field.

Thanks for pointing out. I would modify my PR summary later.
I’ve also tried multiple times about the suggestion from Ash. But I can’t see the ci fail because of alembic check after I delete or add field. I’m not really sure the root cause about it but I could try it again. Then we could see the result. Thanks a lots.

I've added a field named test in dag and tried locally with breeze shell which work well to detect the change.

$ breeze shell "cd airflow-core/src/airflow && alembic check"

[2025-05-06T12:23:10.917+0000] {migration.py:207} INFO - Context impl SQLiteImpl.
[2025-05-06T12:23:10.919+0000] {migration.py:210} INFO - Will assume non-transactional DDL.
[2025-05-06T12:23:11.124+0000] {compare.py:400} INFO - Detected added column 'dag.test_field'
[2025-05-06T12:23:11.158+0000] {messaging.py:71} ERROR - New upgrade operations detected: [('add_column', None, 'dag', Column('test_field', String(length=2000), table=<dag>))]
  FAILED: New upgrade operations detected: [('add_column', None, 'dag', Column('test_field', String(length=2000),
  table=<dag>))]
Error 255 returned

but

$ pre-commit run check-model-changes
Check if model changes require DB migration..............................Passed

I've added a field named test in dag and tried locally with breeze shell which work well to detect the change.

$ breeze shell "cd airflow-core/src/airflow && alembic check"

[2025-05-06T12:23:10.917+0000] {migration.py:207} INFO - Context impl SQLiteImpl.
[2025-05-06T12:23:10.919+0000] {migration.py:210} INFO - Will assume non-transactional DDL.
[2025-05-06T12:23:11.124+0000] {compare.py:400} INFO - Detected added column 'dag.test_field'
[2025-05-06T12:23:11.158+0000] {messaging.py:71} ERROR - New upgrade operations detected: [('add_column', None, 'dag', Column('test_field', String(length=2000), table=<dag>))]
  FAILED: New upgrade operations detected: [('add_column', None, 'dag', Column('test_field', String(length=2000),
  table=<dag>))]
Error 255 returned

but

$ pre-commit run check-model-changes
Check if model changes require DB migration..............................Passed

wow. That's nice

Did you check if we can have this as a test in utils/test_db.py

It works as well in my local computer. Let me test it on ci
Thanks for the suggestion.

There's a bug in CI that might be causing all these to pass: https://github.com/apache/airflow/actions/runs/14898553456/job/41845929327?pr=49002#step:5:5931
I'm working on it

Thanks a lots!

Rebased and hope ci failed!

So, the bug I fixed is unrelated. I think I understand what's happening. The DB is initialized from the ORM, and we try to run the file migration, too, by running downgrade and upgrade commands. In the end, the new field you added is already in the DB. When the alembic check command is run, the database already has the new field, and therefore, it's not detected.

In airflow 2, we could easily detect this new field because our tests initializes the database from the migration files instead of the ORM.

Yes, I think that is unrelated. What you said is match with my local experiment. It would only successfully detect the error when I init with right ORM and then try add/delete something. I still try to figure how to deal with this without breaking the whole initialization process.

Close now and would come back if I have better idea about this.